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DETAILED ACTION 

1. Claims 1-26 Pending. 

Response to Arguments 

2. Applicant's arguments filed 5/14/2007 have been fully considered but they are 
not persuasive. 

As per Applicants arguments directed towards Claim 1 , Examiner agrees that 
Amiri fails to disclose at least one of said communication grants including aid protected 
data, but notes that the disclosure of Yun is relied upon to teach this limitation, not the 
disclosure Amiri. Examiner notes that both Amiri and Yun describe locking mechanisms 
and that although Yun is dealing with resource locking between processes while Amiri 
deals with resource locking in a shared storage environment, the behavior of the locking 
mechanism is the focus of what the Examiner is relying upon. Fundamentally, the 
locking mechanisms in place to control access to resources by processes and those in 
place to control access to resources in a network storage environment are the same 
and as such, Examiner feels that the two references qualify as analogous art. 

Examiner respectfully disagrees with Applicants assessment that the 
combination of Amiri and Yun would not work as Yun accesses data from native 
storage. Note that the cited sections of Yun do not rely on the data being accessed 
from native storage, but rather, that the locking mechanism would be indifferent as to 
where the data originated from. As the native storage data access it is not an integral 
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part of the disclosure of Yun, Examiner is not compelled to agree that Yun teaches 
away from the disclosure of Amiri. 

As per Applicants arguments directed towards Claim 2, Examiner feels that the 
action sufficiently demonstrated a situation arising in Amiri in which a communicated 
grant would not include the protected data (e.g. in the case of the first communicated 
grant). Examiner maintains the argument that Amiri demonstrates that the first 
communicated grant would not include protected data for the reasons given in the 
rejection. 

As per Applicants arguments directed towards Claim 3, Applicant states that the 
rejection failed to include an indication of protected data and the protected data itself, as 
they are two separate limitations. Examiner notes that the citation used in the rejection 
clearly indicated that the message included diffs and write notices. As examiner pointed 
out in the previous action, diffs are equated to the protected data and the write notices 
are equated to the indication of the protected data, it can be seen that both limitations 
are addressed by the rejection. 

As per Applicants arguments directed towards Claim 4, Examiner notes that the 
fact that the whole page is transferred in base HLRC (the portion of the cited text that 
Applicant seems to take issue with) was not intended to give the citation any more 
relevance, but was merely included to make the cited sentence complete. Note that the 
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relevance of the cited text lies in the fact that it states that the cliffs (e.g. protected data) 
are transferred for the purposes of page updates. In this case, as only the diffs are 
being transferred, some indication of the next requestor must be included in the transfer 
messages. Note that if this were note included then the protected data would not be 
able to be transferred, as it would have no transfer destination. As this is the case, this 
indication of the next requestor will also act as the indication as to whether or not the 
lock manager is the next requestor. 

As per Applicants arguments directed towards Claim 5, Examiner notes that a 
requestor would not accept a lock on data which it did not request. As such, the lock 
request acts as an indication as to whether the protected data will be accepted (e.g. it 
will be accepted if the protected data includes the requested data). 

As per Applicants arguments directed towards Claims 6 and 7, Examiner notes 
that as only the diffs are being transferred, some indication of the next requestor must 
be included in the transfer messages. Note that if this were note included then the 
protected data would not be able to be transferred, as it would have no transfer 
destination. As this is the case, this indication of the next requestor will also act as an 
indication as to whether or not the lock manager is the next requestor. Furthermore see 
Examiner comments directed towards Claim 1 above. 
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Applicants arguments directed towards Claims 8-26 where substantially the 
same as those indicated above, and thus are considered to be addressed therein. 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1-26 rejected under 35 U.S.C. 103(a) as being unpatentable over Amiri in 
viewofYun. 

As per Claim 1, Amiri discloses an apparatus for protecting data using locks (i.e. 
"Under this scheme, a centralized lock server provides locking on low-level storage block ranges. " The 
preceding text excerpt clearly indicates that data is protected using locks.) (Page 6, Column 1, Paragraph 
3), the apparatus comprising: a lock manager configured to control access via a lock to 
protected data maintained in native storage independent of the lock manager (i.e. "Under 
this scheme, a centralized lock server provides locking on low-level storage block ranges. A BST 
executing at a host acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of 
target ranges by sending a single lock message to the lock server" The preceding text excerpt clearly 
indicates that the lock manager (e.g. lock server) controls access to data in native storage at local hosts.) 
(Page 6, Column 1, Paragraph 3), wherein the lock manager does not access said protected 
data from said native storage (i.e. "Under this scheme, a centralized lock server provides locking on 
low-level storage block ranges. A BST executing at a host acquires an exclusive (for a devwrite) or a 
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shared (for a devread) lock on a set of target ranges by sending a single lock message to the lock server 
The lock server queues a hosts request if there is an existing lock on any part of the requested range. " 
The preceding text excerpt clearly indicates that the lock manager does not access the protected data on 
a lock grant, but merely acknowledges and either grants or queues the request.) (Page 6, Column 1, 
Paragraph 3); and a plurality of requesters ((i.e. "Under this scheme, a centralized lock server 

provides locking on low-level storage block ranges. A BST executing at a host acquires an exclusive (for 
a devwrite) or a shared (for a devread) lock on a set of target ranges by sending a single lock message 
to the lock server. The lock server queues a hosts request if there is an existing lock on any part of the 
requested range." The preceding text excerpt clearly indicates that a plurality of requestors (e.g. a BST 
executing at a host) exists.) (Page 6, Column 1, Paragraph 3); wherein the lock manager is 
configured to receive lock requests for the lock from each of the plurality of requesters 
(i.e. " Under this scheme, a centralized lock server provides locking on low-level storage block ranges. A 
BST executing at a host acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set 
of target ranges by sending a single lock message to the lock server. The lock server queues a hosts 
request if there is an existing lock on any part of the requested range. " The preceding text excerpt clearly 
indicates that the lock manager/server recives a plurality of lock requests from the plurality of requestors.) 
(Page 6, Column 1, Paragraph 3), and to selectively grant said lock requests which includes 
communicating grants from the lock manager to the plurality of requesters (i.e. "Under this 
scheme, a centralized lock server provides locking on low-level storage block ranges. A BST executing at 
a host acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of target ranges by 
sending a single lock message to the lock server. The lock server queues a hosts request if there is an 
existing lock on any part of the requested range. Once conflicting locks have been released, the server 
grants the request." The preceding text excerpt clearly indicates that locks are selectively granted based 
on availability and lock grant messages are sent to the requestors.) (Page 6, Column 1, Paragraph 3). 
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Amiri fails to disclose at least one of said communicated grants includes said 
protected data. 

Yun discloses at least one of said communicated grants includes said protected 
data (i.e. "Diffs of selected pages are sent with write notices as a lock grant message. " The preceding 
text excerpt clearly indicates that the protected data (e.g. diffs) are included with the lock grant message.) 
(Page 529, Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 

invention to modify the teachings of Amiri with the teachings of Yun to include at least 
one of said communicated grants includes said protected data with the motivation of 
reducing the average waiting time and amount of massages in locking systems (Yun, 
Abstract). 

As per Claim 2, Amiri discloses at least one of said communicated grants does 
not include said protected data (i.e. "The lock server queues a hosts request if there is an existing 
lock on any part of the requested range. Once conflicting locks have been released, the server grants the 
request" The preceding text excerpt clearly indicates that locks are selectively granted based on 
availability and lock grant messages are sent to the requestors. Note as the lock server does not have 
access to the local files, the first communicated grant for a specific range of protected data would not 
include the protected data due to the lock manager/server not being able to access it.) (Page 6, Column 
1, Paragraph 3). 

As per Claim 3, Amiri fails to disclose each of said communicated grants includes 
an indication of whether or not said protected data is being communicated therewith. 
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Yun discloses each of said communicated grants includes an indication of 
whether or not said protected data is being communicated therewith (i.e. "Diffs of selected 
pages are sent with write notices as a lock grant message." The preceding text excerpt clearly indicates 
the grant message that includes the protected data also includes write notices (e.g. indication of the 
protected data/diffs).) (Page 529, Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 

invention to modify the teachings of Amiri with the teachings of Yun to include each of 
said communicated grants includes an indication of whether or not said protected data 
is being communicated therewith with the motivation of reducing the average waiting 
time and amount of massages in locking systems (Yun, Abstract). 

As per Claim 4, Amiri fails to disclose each of said communicated grants includes 
an indication of whether or not said protected data is requested to be sent to the lock 
manager with a corresponding release of the lock. 

Yun discloses each of said communicated grants includes an indication of 
whether or not said protected data is requested to be sent to the lock manager with a 
corresponding release of the lock (i.e. "To make a page up-to-date only diffs are transferred while 
the whole page is transferred in base HLRC. " The preceding text excerpt along with Figure 2 clearly 
indicates that if no other processes are requesting the lock, that the protected data is written back to 
storage, rather than being forwarded to a next acquiring process. In order to make this determination and 
perform this operation, an indication of whether or not to forward the protected data must be included in 
the grant message.) (Figure 2; Page 530, Column 1, Paragraph 1). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include an 
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indication of whether or not said protected data is requested to be sent to the lock 
manager with a corresponding release of the lock with the motivation of reducing the 
average waiting time and amount of massages in locking systems (Yun, Abstract). 

As per Claim 5, Amiri fails to disclose each of said lock requests includes an 
indication of whether or not the corresponding one of the plurality of requesters will 
accept said protected data from the lock manager. 

Yun discloses each of said lock requests includes an indication of whether or not 
the corresponding one of the plurality of requesters will accept said protected data from 
the lock manager (i.e. "Acquirer sends a lock request with information of expected pages to be used 
inside a critical section. " The preceding text excerpt clearly indicates that the request includes an 
indication of what pages of the protected data will be needed by the requesting process. This will indicate 
whether the process will accept the current pages of the protected data from the lock manager.) (Page 
529, Paragraph 2). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include an 
indication of whether or not the corresponding one of the plurality of requesters will 
accept said protected data from the lock manager with the motivation of reducing the 
average waiting time and amount of massages in locking systems (Yun, Abstract). 

As per Claims 6, 8, and 10, Yun discloses a method performed by a lock 
manager, computer readable medium, and lock manager controlling access to protected 
data maintained in native storage independent of the lock manager (i.e. "Under this scheme, 
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a centralized lock server provides locking on low-level storage block ranges. A BST executing at a host 
acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of target ranges by 
sending a single lock message to the lock server." The preceding text excerpt clearly indicates that the 
lock manager (e.g. lock server) controls access to data in native storage at local hosts.) (Page 6, Column 
1, Paragraph 3), wherein the lock manager does not access said protected data from said 

native Storage (i.e. "Under this scheme, a centralized lock server provides locking on low-level storage 

block ranges. A BST executing at a host acquires an exclusive (for a devwrite) or a shared (for a 
devread) lock on a set of target ranges by sending a single lock message to the lock server. The lock 
server queues a hosts request if there is an existing lock on any part of the requested range. " The 
preceding text excerpt clearly indicates that the lock manager does not access the protected data on a 
lock grant, but merely acknowledges and either grants or queues the request.) (Page 6, Column 1, 
Paragraph 3), the method comprising: receiving a release of a lock for use in controlling 
access to said protected data (i.e. " Under this scheme, a centralized lock server provides locking 
on low-level storage block ranges. A BST executing at a host acquires an exclusive (for a devwrite) or a 
shared (for a devread) lock on a set of target ranges by sending a single lock message to the lock server. 
The lock server queues a hosts request if there is an existing lock on any part of the requested range. " 
The preceding text excerpt clearly indicates that the lock manager/server receives a plurality of lock 
requests from the plurality of requestors.) (Page 6, Column 1, Paragraph 3); identifying a next 
requester to be granted the lock in response to said receiving the release of the lock (i.e. 

" Under this scheme, a centralized lock server provides locking on low-level storage block ranges. A BST 
executing at a host acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of 
target ranges by sending a single lock message to the lock server The lock server queues a hosts 
request if there is an existing lock on any part of the requested range. Once conflicting locks have been 
released, the server grants the request." The preceding text excerpt clearly indicates that locks are 
selectively granted based on availability (e.g. if a lock is busy upon receipt of a request a next requestor is 
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identified) and lock grant messages are sent to the requestors.) (Page 6, Column 1, Paragraph 3); and 
sending the grant message to the next requester (i.e. " Under this scheme, a centralized lock 

server provides locking on low-level storage block ranges. A BST executing at a host acquires an 
exclusive (for a devwrite) or a shared (for a devread) lock on a set of target ranges by sending a single 
lock message to the lock server. The lock server queues a hosts request if there is an existing lock on 
any part of the requested range. Once conflicting locks have been released, the server grants the 
request." The preceding text excerpt clearly indicates that locks are selectively granted based on 
availability and lock grant messages are sent to the requestors.) (Page 6, Column 1, Paragraph 3). 

Amiri fails to disclose that the protected data is included in the release and grant 
messages and that the protected data is copied from the release to the grant message. 

Yun discloses that the protected data is included in the release and grant 
messages and that the protected data is copied from the release to the grant message 
(i.e. "Releaser of that lock decides pages to send diffs based on the information from the lock request. To 
minimize the effect of diff accumulation problem [8], selection is based on the size of diffs to be sent for a 
page. If it exceeds a page size, diffs for that page are not sent. Diffs of selected pages are sent with write 
notices as a lock grant message." The preceding text excerpt clearly indicates that the protected data 
(e.g. diffs) are included with the lock grant message. Note as the lock server does not have access to the 
local files, the first communicated grant for a specific range of protected data would not include the 
protected data due to the lock manager/server not being able to access it. Note that in order for the 
protected data/diffs to move from the release to the grant message, it must be copied there.) (Page 529, 
Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include the 
protected data is included in the release and grant messages and that the protected 
data is copied from the release to the grant message with the motivation of reducing the 
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average waiting time and amount of massages in locking systems (Yun, Abstract). 

As per Claims 7, 9, and 1 1 , Amiri fails to disclose the grant message includes an 
indication of that said protected data is requested to be sent to the lock manager in a 
release message corresponding to the grant message if another requester is waiting for 
the lock, else an indication that said protected data is not requested to be sent to the 
lock manager in the release message. 

Yun discloses the grant message includes an indication of that said protected 
data is requested to be sent to the lock manager in a release message corresponding to 
the grant message if another requester is waiting for the lock, else an indication that 
said protected data is not requested to be sent to the lock manager in the release 
message (i.e. The Figure 2 indicates that if another process is requesting the lock, the protected data is 
sent with the release and grant messages, but if no other process is requesting the lock then the data is 
stored (e.g. not sent to the lock manager). In order to produce this behavior, an indication of whether or 
not to transmit the protected data back to the lock manager must be present.) (Figure 2). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include the grant 
message includes an indication of that said protected data is requested to be sent to the 
lock manager in a release message corresponding to the grant message if another 
requester is waiting for the lock, else an indication that said protected data is not 
requested to be sent to the lock manager in the release message with the motivation of 
reducing the average waiting time and amount of massages in locking systems (Yun, 
Abstract). 



Application/Control Number: 10/811,044 



Art Unit: 2165 



Page 13 



As per Claims 12, 17, and 22, Yun discloses a method performed by a lock 
manager, computer readable medium, and lock manager controlling access to protected 
data maintained in native storage independent of the lock manager (i.e. "Under this scheme, 
a centralized lock server provides locking on low-level storage block ranges. A BST executing at a host 
acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of target ranges by 
sending a single lock message to the lock server." The preceding text excerpt clearly indicates that the 
lock manager (e.g. lock server) controls access to data in native storage at local hosts.) (Page 6, Column 
1, Paragraph 3), wherein the lock manager does not access said protected data from said 
native Storage (i.e. "Under this scheme, a centralized lock server provides locking on low-level storage 
block ranges. A BST executing at a host acquires an exclusive (for a devwrite) or a shared (for a 
devread) lock on a set of target ranges by sending a single lock message to the lock server. The lock 
server queues a hosts request if there is an existing lock on any part of the requested range. " The 
preceding text excerpt clearly indicates that the lock manager does not access the protected data on a 
lock grant, but merely acknowledges and either grants or queues the request.) (Page 6, Column 1, 
Paragraph 3), the method comprising: receiving locking requests for a lock controlling 
access to said protected data from a first requester and a second requester (i.e. "Under 
this scheme, a centralized lock server provides locking on low-level storage block ranges. A BST 
executing at a host acquires an exclusive (for a devwrite) or a shared (for a devread) lock on a set of 
target ranges by sending a single lock message to the lock server. The lock server queues a hosts 
request if there is an existing lock on any part of the requested range. Once conflicting locks have been 
released, the server grants the request." The preceding text excerpt clearly indicates that requests for the 
locks are received by multiple requesters (e.g. a first and second requester).) (Page 6, Column 1, 
Paragraph 3); sending a first grant message to the first requester, the first grant message 
not including said protected data (i.e. " Under this scheme, a centralized lock server provides 
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locking on low-level storage block ranges. A BST executing at a host acquires an exclusive (for a 
devwrite) or a shared (for a devread) lock on a set of target ranges by sending a single lock message to 
the lock server The lock server queues a hosts request if there is an existing lock on any part of the 
requested range. Once conflicting locks have been released, the server grants the request" The 
preceding text excerpt clearly indicates that locks are selectively granted based on availability and lock 
grant messages are sent to the requestors. Note as the lock server does not have access to the local 
files, the first communicated grant for a specific range of protected data would not include the protected 
data due to the lock manager/server not being able to access it.) (Page 6, Column 1, Paragraph 3) and 

receiving a first release message corresponding to the first grant message for the lock 
from the first requester (i.e. "When all I/O requests in the BST complete, the host sends an unlock 
message to the lock server." The preceding text excerpt clearly indicates that lock release (e.g. unlock) 
messages are received from the lock holders which correspond to the lock grant messages.) (Page 6, 
Column 1, Paragraph 3). 

Amiri fails to disclose in response to identifying one or more requesters is waiting 

for the lock after the first requester, including an indication to return said protected data 
in the first grant message and the first release message including said protected data. 

Yun Discloses disclose in response to identifying one or more requesters is 
waiting for the lock after the first requester, including an indication to return said 
protected data in the first grant message (i.e. "Releaser of that lock decides pages to send diffs 
based on the information from the lock request. To minimize the effect of diff accumulation problem [8], 
selection is based on the size of diffs to be sent for a page. If it exceeds a page size, diffs for that page 
are not sent. Diffs of selected pages are sent with write notices as a lock grant message." The preceding 
text excerpt clearly indicates that if the lock request information is received, indicating another process is 
requesting the lock, that the protected data (e.g. diffs) will be returned. This indicates that an indication to 
return the protected data was also transmitted.) (Page 529, Paragraph 3) and the first release 
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message including said protected data (i.e. "Releaser of that lock decides pages tosenddiffs 
based on the information from the lock request. To minimize the effect of diff accumulation problem [8], 
selection is based on the size of diff s to be sent for a page. If it exceeds a page size, diffs for that page 
are not sent. Diffs of selected pages are sent with write notices as a lock grant message. " The preceding 
text excerpt clearly indicates that the release message includes the protected data (e.g. diffs).) (Page 
529, Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include in 
response to identifying one or more requesters is waiting for the lock after the first 
requester, including an indication to return said protected data in the first grant message 
and the first release message including said protected data with the motivation of 
reducing the average waiting time and amount of massages in locking systems (Yun, 
Abstract). 

As per Claims 13, 18, and 23, Amiri fails to disclose sending a second grant 
message to the second requester, the second grant message including said protected 
data, and an indication of whether or not to send said protected data in a second 
release message. 

Yun discloses sending a second grant message to the second requester, the 
second grant message including said protected data (i.e. "Releaser of that lock decides pages 
to send diffs based on the information from the lock request. To minimize the effect of diff accumulation 
problem [8], selection is based on the size of diffs to be sent for a page. If it exceeds a page size, diffs for 
that page are not sent Diffs of selected pages are sent with write notices as a lock grant message. " The 
preceding text excerpt clearly indicates that the protected data is sent in the second grant message.) 
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(Page 529, Paragraph 3), and an indication of whether or not to send said protected data in 
a second release message (i.e. "Acquirer sends a lock request with information of expected pages 
to be used inside a critical section... Releaser sends diffs for expected pages to be used by acquirer. " 
The preceding text excerpt clearly indicates that an indication of the next requestor, if one exists, is sent. 
This acts as an indication to send the protected data along with the release message.) (Page 529, 
Paragraph 2; Page 528, Column 2, Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include the grant 
message includes sending a second grant message to the second requester, the 
second grant message including said protected data, and an indication of whether or 
not to send said protected data in a second release message with the motivation of 
reducing the average waiting time and amount of massages in locking systems (Yun, 
Abstract). 

As per Claims 14, 19, and 24, Amiri fails to disclose the second grant message 
includes an indication to send said protected data in the second release message in 
response to identifying another requestor is waiting for access to the lock. 

Yun discloses the second grant message includes an indication to send said 
. protected data in the second release message in response to identifying another 
requestor is waiting for access to the lock (i.e. "Acquirer sends a lock request with information of 
expected pages to be used inside a critical section... Releaser sends diffs for expected pages to be used 
by acquirer." The preceding text excerpt along with Figure 2 clearly indicates that if another process is 
waiting for access to the lock, it is indicated in the grant message, and the protected data (e.g. diffs) are 
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sent with the release message. This behavior necessitates that an indication must be made to of whether 
or not to send the protected data back in the release message based on the number of requestors waiting 
for the lock.) (Figure 2; Page 529, Paragraph 2; Page 528, Column 2, Paragraph 3). 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include the 
second grant message includes an indication to send said protected data in the second 
release message in response to identifying another requestor is waiting for access to 
the lock with the motivation of reducing the average waiting time and amount of 
massages in locking systems (Yun, Abstract). 

As per Claims 15, 20, and 25, Amiri fails to disclose the second grant message 
includes an indication not to send said protected data in the second release message in 
response to identifying another requestor is not waiting for access to the lock. 

Yun discloses the second grant message includes an indication not to send said 
protected data in the second release message in response to identifying another 
requestor is not waiting for access to the lock (i.e. "Acquirer sends a lock request with 
information of expected pages to be used inside a critical section . . . Releaser sends diffs for expected 
pages to be used by acquirer/' The preceding text excerpt along with Figure 2 clearly indicates that if 
another process is not waiting for the lock, another lock request will not be present in the grant message, 
and the protected data will be stored instead of sent with the release message. This behavior 
necessitates that an indication must be made to of whether or not to send the protected data back in the 
release message based on the number of requestors waiting for the lock.) (Figure 2; Page 529, 
Paragraph 2; Page 528, Column 2, Paragraph 3). 



Application/Control Number: 10/811 ,044 Page 1 8 

Art Unit: 2165 

It would have been obvious to one skilled in the art at the time of Applicants 
invention to modify the teachings of Amiri with the teachings of Yun to include the 
second grant message includes an indication not to send said protected data in the 
second release message in response to identifying another requestor is not waiting for 
access to the lock with the motivation of reducing the average waiting time and amount 
of massages in locking systems (Yun, Abstract). 

As per Claims 16, 21 , and 26, Amiri fail to disclose the second grant message 
includes an indication not to send said protected data in the second release message; 
and the method comprises in response to said indication not to send said protected data 
in the second release message, the second requester storing said protected data and 
not including said protected data in the second release message. 

Yun discloses the second grant message includes an indication not to send said 
protected data in the second release message (i.e. "Acquirer sends a lock request with 
information of expected pages to be used inside a critical section . ..Releaser sends diffs for expected 
pages to be used by acquirer." The preceding text excerpt along with Figure 2 clearly indicates that if 
another process is not waiting for the lock, the protected data will not be present in the grant message. 
This behavior necessitates that an indication must be made to of whether or not to send the protected 
data back in the release message.) (Figure 2; Page 529, Paragraph 2; Page 528, Column 2, Paragraph 
3); and the method comprises in response to said indication not to send said protected 
data in the second release message, the second requester storing said protected data 
and not including said protected data in the second release message (i.e. Figure 2 clearly 
indicates that if no other process is requesting the lock on the protected data, the protected data is stored, 



Application/Control Number: 10/811,044 Page 19 

Art Unit: 2165 

and it is not included in the release message.This behavior necessitates that an indication must be made 
to of whether or not to send the protected data back in the release message based on the number of 
requestors waiting for the lock.) (Figure 2). 

It would have been obvious to one skilled in the art at the time of Applicants 

invention to modify the teachings of Amiri with the teachings of Yun to include the 

second grant message includes an indication hot to send said protected data in the 

second release message; and the method comprises in response to said indication not 

to send said protected data in the second release message, the second requester 

storing said protected data and not including said protected data in the second release 

message with the motivation of reducing the average waiting time and amount of 

massages in locking systems (Yun, Abstract). 

3. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
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the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 
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